This must be optional, both of these need to have a specific configuration option to turn them on.

To give you an idea of why this can cause problems say I have an environment that knows nothing about X-Forwarded-Prefix, but security is done by the front end proxy.

An attacker could send a request to / but with X-Forwarded-Prefix set to /secure. The front end proxy will just see /, and allow it, but then Quarkus will serve up content from /secure.

If you are going to enable these options they can only be turned on in an environment where you know these headers will only be set by a trusted source.

Thanks for the explanation! :-)

For clarification, when you mentioned "both of these", do you mean x-forwarded-host/x-forwarded-server as well?

yes

Can the "quarkus.http.proxy-address-forwarding" config property be enough to prevent those scenarios?

Hmm, I need to do some more research on this. The question is do frontend proxies that send one or more of these always send all of them (or make sure to disallow forwarding them)?

If all the main implementations do this then as this is not really a standard we are probably fine to just use a single switch. If not then maybe even our current configuration is too coarse grained.

@ejba Looks like a switch per header can be the most secure solution based on what you've discussed with @stuartwdouglas and @kraeftbraeu, please follow up with this update.

May be it can make sense to split the PR in 2 parts, the 1st part will only deal with X-Forwarded-Host and X-Forwarded-Server to accelerate it, X-Forwarded-Prefix related updated can be discussed further as needed in another (draft) PR...
Sounds good ?
Cheers, Sergey

@sberyozkin, just two questions:

• Should I keep this quarkus.http.proxy-address-forwarding property?
• Should I default every x-forward-* header as disabled, despite the backward compatibility?

I like the approach with two separate PRs, since it helps separate needs. To be honest I still dont get the security issues with the prefix header. Isnt it set by the reverse proxy? Or is it possible that the reverse proxy just forwards these headers?

So, for the host/server selection two separate switches shall be used with a startup exception when both are set to true?
Or can we stay with the current solution but we extend the documentation (and maybe the startup log) with a hint to this security issue when using this option?

The property quarkus.http.proxy-address-forwarding says if the absoluteUri shall be recalculated from forwarded-headers in principle. I'd say that should be kept.

When we start the additional properties

• quarkus.http.allow-x-forwarded-server
• quarkus.http.allow-x-forwarded-host
• quarkus.http.allow-x-forwarded-prefix
  and the second one is no more enabled by default, backward compatibility is broken.

I'm new to the quarkus project but IMHO broken backward compatibility reduces trust to a software project and should definitely be avoided if possible.

Of course security issues are still important. But in the end the key is the awareness by the quarkus users. And I would prefer to write a good documentation rather than making the configuration a little more complicated to push the user to think about security issues.

@stuartwdouglas what do you think?

Ah I see, #10138 is the new PR.